1. Field of the Invention
This invention relates to computer system operating software, and more particularly to a system and method for implementing a CPU-independent virtual memory using a hardware-dependent virtual memory interface which enables the virtual memory software code to be easily ported between unrelated CPU's.
2. Description of the Background Art
Computer facilities that automatically fold programs and data between two or more memory levels are called virtual memory systems. The basic object of virtual memory is to permit programs with very large address space to run as if the programs were loaded in Random Access Memory (RAM). In virtual systems, RAM serves as a window onto the entire address space held in secondary storage such as a disk. If the window is big enough, and if it accurately reflects the active part of total memory, the technique works extremely well.
The success of virtual memory exploits the characteristic that programs tend to access small portions of memory over fairly long periods of computer time. Code loops and manipulations of a data structure are examples of programs that can take advantage of virtual memory. The virtual memory system must detect and maintain in RAM only the working set of a program. As activity gradually shifts to other memory regions, these areas of secondary storage are automatically accessed and brought into RAM. The goal of a virtual memory system is to minimize secondary storage accesses.
The many advantages of a virtual memory system are well known in the art. Foremost, it removes the limit on program size imposed by RAM size, and thus programs execute correctly regardless of actual RAM size. As the size of available RAM increases, program size has also continued to increase making it even more imperative that a virtual memory system be incorporated in a computer system, particularly in a minicomputer system.
Referring now to FIG. 1, a computer system of the prior art is shown. A CPU is connected to a keyboard and a CRT. A common databus connects a disk drive, RAM, ROM, and various software modules to the CPU. The software modules include an operating system (OS), applications, and virtual memory. The OS is for controlling the operation and execution of the computer system. Applications are the programs containing the executable codes that are executed by the CPU and controlled by the operating system.
Referring now to FIG. 2, a block diagram depicting the interaction between various software components and the hardware of the computer system of FIG. 1 is shown. The OS interacts with the applications, the hardware and the virtual memory. A virtual memory (VM) manager interacts with the OS and the hardware in the management of the virtual memory. The VM manager contains a memory management unit (MMU) (not shown) which performs operations within the virtual memory (VM). The MMU is special hardware designed for the virtual memory (VM). The VM manager contains both high level codes and low level codes that control the operation of the virtual memory. The high level codes make up the bulk of the VM manager while the low level codes, which comprise the memory management unit (MMU) codes, make up a small portion of the VM manager. The high level codes of the VM manager contain complex high level codes for implementing various routines and algorithms that are used to manage the operation of the virtual memory. The low level MMU codes are short and simple compared to the high level code of the VM manager. The low level MMU codes primarily control the machine level operations of the MMU.
As depicted in the prior art, the virtual memory is an integral part of the operating system and hardware. The high level codes and the low level codes of the VM manager are intertwined with each other. Consequently, the virtual memory is highly dependent on the characteristics of the processor. A significant problem with virtual memory designs is that the virtual memory designs are generally not portable between differing processors which makes virtual memory designs subject to obsolescence as processors evolve and processor architectures change. Much of the time spent in developing and debugging the complex code of the VM manager is lost whenever a virtual memory design is changed. Thus, there has been a significant need for a virtual memory system that is processor-independent and is portable between differing processors. A CPU-independent virtual memory enables the virtual memory to adapt to different processor designs as computer architectures change and evolve.